Streaming applications are getting increasingly important, both in fixed networks like the Internet and in the context of 3rd Generation mobile networks like UMTS (Universal Mobile Telephone System). Streaming technology allows a nearly instantaneous access for the users to pre-stored content without the necessity to transfer a complete file before presentation. Streaming applications are widely used for video and audio media.
In a streaming application, a stream of data packets is transmitted from a server being the original sender to a client as final receiver of the data packets. Packets may be lost during the transmission, e.g. due to transmission errors or due to dropping by congestion avoidance methods. Packets may also be delayed, for example due to link characteristics, link congestion and retransmissions of lost packets. Different individual delays for the packets result in a delay jitter within the packet stream. The data rate of a stream can also have variations due to the encoding of the media. For example, one option to transmit a video sequence is the transmission of differences between consecutive images. This leads to a high data rate in case of many differences while the data rate is low if several consecutive images are identical.
Each packet has a presentation time at which it must be available at the client for processing and presentation, e.g. for display in a video or audio sequence. Packets, which are lost or arrive too late, cannot be played out. As a consequence, streaming applications are sensitive both against packet loss and delays. Therefore, streaming clients generally have a buffer, which allows to compensate transmission delay jitter and the delay introduced by the retransmission of lost or erroneous data packets. Both the client memory required for buffering and the link bandwidth are however limited and expensive resources, especially in mobile applications. Therefore, they are often selected close to the minimum requirements for a desired quality of service.
The RTP (Real-Time Transport Protocol) protocol allows an efficient delivery of data packets for real-time media like audio or video files. RTP is transported on UDP (User Datagram Protocol), which does not include a retransmission mechanism for the recovery of lost or corrupted packets. Therefore, a retransmission mechanism on top of RTP is required to compensate packet losses. The RTCP (RTP control protocol) specifies a data packet format that can be used to implement such a retransmission mechanism. The retransmission control method is not specified in RTCP to allow adaptations to individual applications. Different retransmission control methods for the RTP protocol are therefore possible based on the RTCP data packet format.
One example of a retransmission method is described in U.S. Pat. No. 6,275,471 When a receiver receives a stream from a sender after an according request, the receiver checks whether there are any lost data packets. If this is the case, the receiver determines a remaining transmission period for the lost data packet, i.e. the latest time at which the packet needs to be available at the receiver for presentation. The remaining transmission period is sent with the negative acknowledgement for the lost data packet to the sender. The sender compares the remaining transmission period with an estimated round-trip time to check whether the requested packet can arrive at the receiver before the required presentation time. If this is the case, the retransmission is performed. Else, the packet is not retransmitted and the receiver constructs the output of the application without the lost packet, e.g. by using error concealment techniques.
Between the server and the client, the data packets are transported by one or several transport networks, typically over a plurality of links with different characteristics. Often, one of said links is a bottleneck for the transmission as it has the lowest data rate and/or a high round trip time, the latter influencing especially the delay of retransmissions. In wireless communication systems, the bottleneck is generally the wireless link to a mobile user equipment, e.g. a mobile phone. European application EP 1 130 839 describes an option to calculate the transmission delay of data packets.
On a link with limited bandwidth, self-congestion may occur. If data packets are retransmitted, the server has to ensure that the total traffic comprising both original packets and retransmitted data packets does not exceed an allowed or guaranteed bitrate. Due to the limitation, original data packets are often delayed when a retransmission is performed, especially if the data rate of the original data packets is close to the link capacity. This delay can disturb the presentation behavior of the data stream by the streaming application, which may be interrupted or may need to apply error correction or concealment.
The data rate may vary considerably for some types of links, e.g. according to the behavior of other users sharing the same resources, while other links provide a constant or nearly constant bandwidth for transmission. For example, UMTS streaming bearers transporting the data packets to mobile clients can be negotiated for specific combinations of guaranteed bitrate, packet loss, and delay for the data packets. Many streaming applications allow an adaptation of the stream to guaranteed parameters, e.g. by selecting the rate of original data below the guaranteed bitrate, allowing a rate of retransmissions according to the difference of selected and guaranteed bitrate. A gateway, e.g. a 3G-GGSN (Gateway GPRS Support Node) in the example of a UMTS system, controls the traffic from the server to the client using a traffic policing function. If the traffic exceeds the guaranteed parameters, packets can be dropped. This can lead to a severe disturbance of the stream presentation, especially if retransmissions increase the bitrate of the stream beyond a guaranteed bitrate.